IBIS Macromodel Task Group Meeting date: 12 December 2009 Members (asterisk for those attending): Adge Hawes, IBM * Ambrish Varma, Cadence Design Systems * Anders Ekholm, Ericsson * Arpad Muranyi, Mentor Graphics Corp. Barry Katz, SiSoft * Bob Ross, Teraspeed Consulting Group Brad Brim, Sigrity Brad Griffin, Cadence Design Systems Chris Herrick, Ansoft Chris McGrath, Synopsys * Danil Kirsanov, Ansoft David Banas, Xilinx Deepak Ramaswany, Ansoft Donald Telian, consultant Doug White, Cisco Systems * Eckhard Lenski, Nokia-Siemens Networks Eckhard Miersch, Sigrity Essaid Bensoudane, ST Microelectronics * Fangyi Rao, Agilent Ganesh Narayanaswamy, ST Micro Gang Kang, Sigrity Hemant Shah, Cadence Design Systems Ian Dodd, consultant Jerry Chuang, Xilinx Joe Abler, IBM * John Angulo, Mentor Graphics John Shields, Mentor Graphics Ken Willis, Cadence Design Systems Kumar Keshavan, Sigrity Lance Wang, Cadence Design Systems Luis Boluna, Cisco Systems Michael Mirmak, Intel Corp. * Mike LaBonte, Cisco Systems Mike Steinberger, SiSoft Mustansir Fanaswalla, Xilinx Patrick O'Halloran, Tiburon Design Automation Paul Fernando, NCSU Pavani Jella, TI Radek Biernacki, Agilent (EESof) * Randy Wolff, Micron Technology Ray Komow, Cadence Design Systems Richard Mellitz, Intel Richard Ward, Texas Instruments Samuel Mertens, Ansoft Sam Chitwood, Sigrity Sanjeev Gupta, Agilent Shangli Wu, Cadence Design Systems Sid Singh, Extreme Networks Stephen Scearce, Cisco Systems Steve Kaufer, Mentor Graphics Steve Pytel, Ansoft Syed Huq, Cisco Systems Syed Sadeghi, ST Micro Ted Mido, Synopsys Terry Jernberg, Cadence Design Systems * Todd Westerhoff, SiSoft Vladimir Dmitriev-Zdorov, Mentor Graphics Vikas Gupta, Xilinx Vuk Borich, Agilent * Walter Katz, SiSoft Zhen Mu, Mentor Graphics ------------------------------------------------------------------------ Opens: - Arpad: This is the last meeting for 2009 - We will next meet Jan 5 2010 - Bob: BUG 109 status -------------------------- Call for patent disclosure: - No one declared a patent. ------------- Review of ARs: - Arpad write section 2 of AMI specification draft - Done - Arpad to write email to reflector noting these two questions to discuss and vote on next meeting. 1. Do we deprecate or require Reserved_Parameters and Model_Specific descriptions? 2. Do we make Format optional? - Done - Arpad: Write a clarification BIRD to discuss accuracy issues related to the various AMI clock_tick algorithms in an IBIS-AMI DLL - TBD - Todd: Update the BIRD for IBIS S-parameter box based on feedback from discussion - No update - Arpad: Write parameter passing syntax proposal (BIRD draft) for *-AMS models in IBIS that is consistent with the parameter passing syntax of the AMI models - TBD - TBD: Propose a parameter passing syntax for the SPICE - [External ...] also? - TBD - Arpad: Review the documentation (annotation) in the macro libraries. - Deferred until a demand arises or we have nothing else to do ------------- New Discussion: Bob discussed BUG 109 status: - It is written so there is no restriction on the type - This was filed by Todd about a week ago - The parser developer can fix the code easily - Todd: It affects type List as well - Arpad: Will the developer fix only what we tell him or the broader issue? - Bob: He will do only what we tell him - Todd: The processing was not implemented correctly - It accepted only a number - Bob: We will pay him to use up our money - He will fix it up well - If type is Integer and value is 1.0 it will work - Arpad: Not sure what extent we need to handle these cases - The parser must not complain about things that are legal - Todd: Agree, that is the very least - Arpad: It should accept a number, string, boolean, or list - Bob: We went one step too far in limiting the syntax - Todd: It should look at type processing in general - The changes should not be restricted to the problem I reported Arpad showed the votes on 2 questions raised last week: - We are voting about the writing of a BIRD draft - Bob: The formatting of the BIRD is critical - We have a commitment to backward compatibility - Does option C mean it is supported forever? - There can not be complicated conditions - We need clarity before we close this - Walter: The intent for 1C and 2C is that any 5.0 file will always work - Simply ignoring Format will do this - Bob: There is no removal of legal syntax in IBIS - Walter: We don't want to have to put Format in examples - The old syntax can be supported, but there should be no examples - Bob: I have been looking at the deleted phrases carefully - Todd: If someone develops a model 6 months from now do they have to put Model_Specific in the model? - Bob: Yes - Arpad: The point of this is to remove it - Todd: We want the new documentation as clean and simple as possible - There should be no more than a footnote to say that they once existed - Bob: That is a desirable goal - Also it can be IBIS 5.1 and that is not an error - Arpad: We always considered .0 spec versions to not be "official" - We are getting ready for a .1 that will be official - We have made changes due to errors in the past - Bob: We could withdraw that part of the spec and start from ground zero - Arpad: It is a relatively minor mistake - Bob: Some people we don't know may be using this - Todd: We can't make the statement that this is dead - The proposal is that a 5.0 model has the keywords - A 5.1 model doesn't have to, but could - Walter: Bob is saying it is OK as long as 5.1 allows the keywords - Bob: How best to document the legacy? - A footnote would be acceptable - Section 6C would move to an appendix section - We have to document what we support - Walter: The choices are about how much to keep in the document - 30% want it required - 65% want it gone - We should be able to only reference the historical stuff - We have to be clear about how 5.0 models will work in 5.1+ - Bob: There should be no harm leaving it in - John: There is a balance between having a clean doc and covering everything that will pass - Walter: Can we leave the old stuff in the BIRD as a block, separate from the new? - We can defer how it goes into the spec - Bob: We can proceed this way - This doesn't affect how we eliminate section 6C - We can't create a rule such that removing Format kill the model - We will take A off the table, but need to clarify B and C - Walter: I will write a new section that is clean - It may have references to the old - Arpad: Does this apply to both questions? - Bob: Both Ambrish: What is the problem with Model_Specific and Reserved_Parameters? - Walter: An IC vendor may want a model to work across all tools - They will want to move Model_Specific to Reserved_Parameters - Existing models with Model_Specific won't work - They are in the wrong branch - Todd: By virtue of moving params for existing files we violate the IBIS compatibility rule - Bob: Now there will be no Model_Specific "escape" - Models will be subject to the rigid parser - Todd: We have to do this to avoid a conflict introducing new parameters - Vendors will do what they have to if we don't serve their needs - Bob: It might be in an appendix - That would not harm the industry - Todd: Not including deprecated HTML in new specs was a good decision - Put this stuff in reduces readability, but IBIS lost that long ago - Bob: Yes now we have a mandate to start fresh AR: Arpad send text representation to Mike L for posting AR: Mike L post Arpad's document Bob: We need to clarify that the DLL never parses the .ami - A text diagram would be good - Walter: I have attempted to clarify this - A non-text drawing would be better - Walter show the section 2 doc - The "|" pipe characters make this very hard to edit - Also graphics would be good - Bob: Agree - I can help convert it back to characters after - WinIBIS can easily insert leading pipes Next meeting: 05 Jan 2009 12:00pm PT -------- IBIS Interconnect SPICE Wish List: 1) Simulator directives